Red Hat Enterprise Linux 7 Implementation

Users and Groups

Module Topics

Users
Groups
Superuser Access
Local User Accounts
Local Group Accounts
User Passwords
Identity Management Services

Users

What Is a User?

Every process (running program) runs as particular user
Every file is owned by particular user
File and directory access are restricted by user
User associated with running process determines files and directories that process can access

Users

Viewing User Information

To view info for current logged-in user, use id

To view info about another user, add username as first argument

[student@desktop1 ~]$ id
uid=1000(student) gid=1000(student) groups=1000(student),10(wheel) context=unconfined_u:nconfined_r:unconfined_t:s0-s0:c0.c1023

To list user associated with file or directory, use ls -l

[student@server1 ~]$ ls -l /tmp
drwx------. 2 gdm     gdm      4096 Jan 24 13:5 orbit-gdm
drwx------. 2 student student  4096 Jan 25 20:0 orbit-student
-rw-r--r--. 1 root    root    23574 Jan 24 13:5 postconf

Users

To view process information, use ps

To view all processes, use a option

To view user associated with process, use u option

[student@server1 ~]$ ps au
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       428  0.0  0.7 152768 14400 tty1     Ss+  Feb03   0:4 /usr/bin/Xorg
root       511  0.0  0.0 110012   812 ttyS0    Ss+  Feb03   0:0 /sbin/agetty
root      1805  0.0  0.1 116040  2580 pts/0    Ss   Feb03   0:0 -bash
root      2109  0.0  0.1 178468  2200 pts/0    S    Feb03   0:0 su - student
student   2110  0.0  0.1 116168  2864 pts/0    S    Feb03   0:0 -bash
student   3690  0.0  0.0 123368  1300 pts/0    R+   11:2   0:00 ps au

Users

User/UID Mapping

Output of id, ls -l, and ps display username
OS tracks users by UID, not name
Names/UID mapping stored in /etc/passwd
Map uses flat-file with seven colon-separated fields per user:
```
username:password:UID:GID:GECOS:/home/dir:shell
```

Field

Description

username

Mapping of a UID to a name for the benefit of human users.

password

Historically, passwords were kept here in encrypted format. Today they are stored in a separate file called /etc/shadow.

UID

User ID, the number that identifies the user at the most fundamental level.

GID

The user’s primary group ID number. Groups are discussed next.

GECOS

Arbitrary text field, usually includes the user’s real name.

/home/dir

The location of the user’s personal data and configuration files.

shell

A program that runs as the user logs in. For a regular user, this is normally the program that provides the user’s command line prompt.

Groups

What Is a Group?

Groups have name and number (GID)
Local groups defined in /etc/group

Primary Groups

Every user has one primary group
- Defined by GID in /etc/passwd
Primary group owns files created by user
Primary group of new user is new group with same name as user
- User is only member of this User Private Group (UPG)

Groups

Supplementary Groups

Users may belong to several supplementary groups, or none
Supplementary members of local groups are listed in last field of /etc/group
```
groupname:password:GID:list,of,users,in,this,group
```
Supplementary groups provide access permissions to files and other resources

References

su(1) and sudo(8) man pages
info libc, GNU C Library Reference Manual, Section 29: Users and groups (requires glibc-devel package)

Superuser Access

root User

root is superuser in Red Hat Enterprise Linux
- Can override normal privileges
- Manages and administers system
Users must escalate privileges to root to install or remove software and manage system files and directories
Fixed devices can be controlled only by root
Removable devices can be controlled by user
root also has unlimited power to damage system
- If root account is compromised, unauthorized person gains control of system
- To minimize risk, log in as standard user and escalate to root only when needed

Transcript:

Most operating systems have some sort of superuser, a user that has all power over the system. This user in Red Hat Enterprise Linux is the root user. This user has the power to override normal privileges on the file system, and is used to manage and administer the system. In order to perform tasks such as installing or removing software and to manage system files and directories, a user must escalate privileges to the root user.

Most devices can only be controlled by root, but there are a few exceptions. For instance, removable devices, such as USB devices, are allowed to be controlled by a normal user. Thus, a non-root user is allowed to add and remove files and otherwise manage a removable device, but only root is allowed to manage "fixed" hard drives by default.

This unlimited privilege, however, comes with responsibility. root has unlimited power to damage the system:remove files and directories, remove user accounts, add backdoors, etc. If the root account is compromised, someone else would have administrative control of the system. Throughout this course, administrators will be encouraged to log in as a normal user and escalate privileges to root only when needed.

Superuser Access

In Linux, root is roughly equivalent to local administrator in Microsoft Windows
Red Hat recommends not logging in directly as root
- Log in as non-root user and use mechanisms such as su, sudo, and PolicyKit to temporarily gain root privileges
- If logged in as root, entire desktop environment unnecessarily runs with admin privileges
- PolicyKit is closest Linux equivalent to Windows UAC
In Windows, admins used to log in directly to perform system admin duties
- Recently, admin account is disabled by default
- User Account Control (UAC) limits admin privileges

Transcript:

The root account on Linux is roughly equivalent to the local Administrator account on MSWN. In Linux, most system administrators log into an unprivileged user account and use various tools to temporarily gain root privileges.

One common practice on MSWN in the past is for the local Administrator user to log in directly to perform system administrator duties. However, on Linux, it is recommended that system administrators should not log in directly as root. Instead, system administrators should log in as a non-root user, and use other mechanisms (su, sudo, or PolicyKit, for example) to temporarily gain superuser privileges.

By logging in as the administrative user, the entire desktop environment unnecessarily runs with administrative privileges. In that situation, any security vulnerability which would normally only compromise the user account has the potential to compromise the entire system.

In recent versions of Microsoft Windows, Administrator disabled by default, and features such as User Account Control (UAC) are used to limit administrative privileges for users until actually needed. In Linux, the PolicyKit system is the nearest equivalent to UAC.

Superuser Access

Switching Users

To switch to a different user, use su [-] <username>
```
[student@desktop1 ~]$ su -
Password:r3dh@t1!
[root@desktop1 ~]#
```
- root implied if username not specified
  - Regular users are prompted for username’s password
  - root not prompted for username’s password
- To start clean login shell environment, use - option
- To start shell with current environment settings, omit - option
To run arbitrary program as another user, use -c option
- Similar to Windows runas utility

References

info su
bash(1) man page

Transcript:

The su command allows a user to switch to a different user account. If a username is not specified, the root account is implied. When invoked as a regular user, a prompt will display asking for the password of the account you are switching to; when invoked as root, there is no need to enter the account password.

The command su username starts a non-login shell, while the command su - username starts a login shell. The main distinction is su - sets up the shell environment as if this were a clean login as that user, while su just starts a shell as that user with the current environment settings.

In most cases, administrators want to run su - to get the user’s normal settings. For more information, see the bash(1) man page.

The su command is most frequently used to get a command line interface (shell prompt) which is running as another user, typically root. However, with the -c option, it can be used like the Windows utility runas to run an arbitrary program as another user. See info su for details.

Superuser Access

Running Commands as root

Linux has coarse-grained permissions model
- root can do everything
- Standard users can do nothing systems related
su temporarily grants standard users root privileges and responsibilities
- Users must know root password
sudo allows users to run commands as root or another user, based on settings in /etc/sudoers
- Users must enter their own password
- Allows administrator to provide fine-grained permissions without exposing root password

Transcript:

Fundamentally, Linux implements a very coarse-grained permissions model: root can do everything, other users can do nothing (systems-related). The common solution previously discussed is to allow standard users to temporarily “become root” using the su command. The disadvantage is that while acting as root, all the privileges (and responsibilities) of root are granted. Not only can the user restart the web server, but they can also remove the entire /etc directory. Additionally, all users requiring superuser privilege in this manner must know the root password.

The sudo command allows a user to be permitted to run a command as root, or as another user, based on settings in the /etc/sudoers file. Unlike other tools such as su, sudo requires users to enter their own password for authentication, not the password of the account they are trying to access. This allows an administrator to hand out fine-grained permissions to users to delegate system administration tasks, without having to hand out the root password.

Superuser Access

Example: Configure sudo to allow user student to run usermod as root

[student@server1 ~]$ sudo usermod -L username
[sudo] password for student:password

All commands executed with sudo are logged in /var/log/secure

[student@server1 ~]$ sudo tail /var/log/secure
...
Feb 19 15:3:36 localhost sudo: student : TTY=pts/0 ; PWD=/home/student ; USER=root ; COMMAND=/sbin/usermod -L student
Feb 19 15:3:36 localhost usermod[16325]: lock user 'student' password
Feb 19 15:3:47 localhost sudo: student : TTY=pts/0 ; PWD=/home/student ; USER=root ; COMMAND=/bin/tail /var/log/secure

Superuser Access

Using sudo From wheel Group

Users in wheel group can use sudo to run commands as any user, including root
Users are prompted for their own password
- Change from Red Hat Enterprise Linux 6 and earlier
- To enable similar behavior on earlier versions, use visudo to edit configuration file and uncomment wheel line
  [root@desktop1 ~]# cat /etc/sudoers ...Output omitted... ## Allows people in group wheel to run all commands %wheel ALL=(ALL) ALL ## Same thing without a password # %wheel ALL=(ALL) NOPASSWD:ALL ...Output omitted...
- Version 6 did not grant wheel special privileges by default
  - Sites using version 6 may be surprised when version 7 grants wheel full sudo privileges

Transcript:

In Red Hat Enterprise Linux 7, all members of group wheel can use sudo to run commands as any user, including root. The user will be prompted for their own password. This is a change from Red Hat Enterprise Linux 6 and earlier. Users who were members of group wheel did not get this administrative access by default in Red Hat Enterprise Linux 6 and earlier.

To enable similar behavior on earlier versions of Red Hat Enterprise Linux, use visudo to edit the configuration file and uncomment the line allowing the group wheel to run all commands.

Red Hat Enterprise Linux 6 did not grant group wheel any special privileges by default. Sites which have been using this group may be surprised when Red Hat Enterprise Linux 7 automatically grants all members of wheel full sudo privileges. This could lead to unauthorized users getting superuser access to Red Hat Enterprise Linux 7 systems.

Historically, membership in group wheel has been used by Unix-like systems to grant or control superuser access.

Superuser Access

PolicyKit

Most system administration applications with a GUI use PolicyKit to authenticate and manage root access
PolicyKit may also prompt wheel group members using a GUI for their own password to get root privileges
- Similar to way sudo grants privileges at shell prompt
PolicyKit grants privileges based on its own configuration settings, separate from sudo

References

su(1), sudo(8), pkexec(1), and polkit(8) man pages
info libc, GNU C Library Reference Manual, Section 29.2: The Persona of a Process (requires glibc-devel package)

Local User Accounts

Creating Users with useradd

Without options, useradd username sets reasonable defaults for all fields in /etc/passwd
- Does not set a password
- User cannot log in until password is set
useradd --help displays basic options that can override defaults
- Most options can also be used with usermod
Some defaults are read from /etc/login.defs
- Example: Range of valid UID numbers and default password aging rules
- Values in /etc/login.defs are used only when creating new users

Local User Accounts

Modifying Users with usermod

usermod --help displays basic options for modifying an account

Option

Description

-c, --comment COMMENT

Adds a value, such as a full name, to the GECOS field

-g, --gid GROUP

Specifies the primary group for the user account

-G, --groups GROUPS

Specifies a list of supplementary groups for the user account

-a, --append

Used with -G to append the user to the supplemental groups mentioned without removing the user from other groups

-d, --home HOME_DIR

Specifies a new home directory for the user account

-m, --move-home

Moves a user home directory to a new location. Must be used with -d

-s, --shell SHELL

Specifies a new login shell for the user account

-L, --lock

Locks a user account

-U, --unlock

Unlocks a user account

Local User Accounts

Deleting Users with userdel

userdel username removes user from /etc/passwd
- Leaves home directory intact by default
userdel -r username removes user and user’s home directory
- Without -r, system ends up with files owned by an unassigned user ID number
- Also occurs when deleted user had files outside home directory
- Can lead to information leakage and security issues
Unless UID is explicitly specified with -u UID, useradd assigns first free UID number available in range 1000 or above to new users
- New users may receive UID that was previously assigned to user that was removed from system
- New users gain ownership of old user’s remaining files

Local User Accounts

Problem

Bob now owns all files that Prince once owned

[root@server1~]# useradd Prince
[root@server1~]# ls -l /home
drwx------. 3 prince  prince    74 Feb  4 15:2 Prince
[root@server1~]# userdel Prince
[root@server1~]# ls -l /home
drwx------. 3    1000    1000   74 Feb  4 15:2 Prince
[root@server1~]# useradd Bob
[root@server1~]# ls -l /home
drwx------. 3 bob     bob       74 Feb  4 15:3 Bob
drwx------. 3 bob     bob       74 Feb  4 15:2 Prince

Solutions

Remove all unowned files when user that created them is deleted
Manually assign unowned files to different user
- root can find unowned files and directories by running:
  find / -nouser -o -nogroup 2> /dev/null

Local User Accounts

Displaying User Information

Use id to display user information, including UID and group memberships
Use id username to display user information for username, including UID number and group memberships

Setting Passwords

Use passwd username to set user’s initial password or change user’s existing password

root can set password to any value

If password does not meet minimum recommended criteria, message displays with prompt to retype password

[root@server1~]# passwd student
Changing password for user student.
New password:redhat123
BAD PASSWORD:The password fails the dictionary check - it is based on a dictionary word
Retype new password:redhat123
passwd:all authentication tokens updated successfully.

Regular user passwords must be at least 8 characters
- Not based on dictionary word, username, or previous password

Local User Accounts

UID Ranges

UID 0: Always assigned to superuser account, root
UID 1-200: System users assigned statically to system processes by Red Hat
UID 201-999: System users assigned dynamically to system processes that do not own files on file system
- Typically assigned from available pool when software that needs them is installed
- Programs run as "unprivileged" system users to limit access to resources required to function
UID 1000+: Available for assignment to regular users

Prior to Red Hat Enterprise Linux 7, UID 1-499 were used for system users and UID 500+ for regular users. Default ranges used by useradd and groupadd can be changed in the /etc/login.defs file.

References

Man pages: useradd(8), usermod(8), and userdel(8)

Local Group Accounts

Supplementary Groups

Group must exist before user can be added to it

To create groups, use groupadd

Use groupadd groupname without options to create groupname with next available GID from range specified in /etc/login.defs

Use -g GID to specify GID (5000 in example)

[student@server1 ~]$ sudo groupadd -g 5000 ateam

Because of the automatic creation of user private groups (GID 1000+), Red Hat recommends setting aside a range of GID numbers for supplementary groups. A higher range avoids collisions with system groups (GID 0-999).

Use -r to create system group using GID from range listed in /etc/login.defs
```
[student@server1 ~]$ sudo groupadd -r appusers
```

Local Group Accounts

Modifying Groups with groupmod

To change a group name to GID mapping, use groupmod
- To specify new name, use -n option
  [student@server1 ~]$ sudo groupmod -n javaapp appusers
- To specify new GID, use -g
  [student@server1 ~]$ sudo groupmod -g 6000 ateam
To delete group, use groupdel
```
[student@server1 ~]$ sudo groupdel javaapp
```
- Group cannot be removed if it is primary group of user
- Check all file systems to ensure that no files remain that were owned by deleted group

Local Group Accounts

Managing Supplementary Groups with usermod

To change user’s primary group, use usermod

[student@server1 ~]$ sudo usermod -g student student

To add user to supplementary group, use usermod -aG groupname username
```
[student@server1 ~]$ sudo usermod -aG wheel elvis
```
To function in append mode, use -a option
- Without -a, user is removed from all supplementary groups

References

Man pages: group(5), groupadd(8), groupdel(8), and usermod(8)

User Passwords

Shadow Passwords and Password Policy

In the past, encrypted passwords were stored in world-readable /etc/passwd
- Thought to be secure until dictionary attacks
- Encrypted passwords (password hashes) were moved to more secure /etc/shadow
- Allowed password aging and expiration features
Three pieces of information are stored in password hash, delimited by $
- Example hash: $1$gCjLa2/Z$6Pu0EK0AzfCjxjv2hoLOB/
- 1: Hashing algorithm (1 indicates MD5 hash, 6 indicates SHA-512)
- gCjLa2/Z: Salt used to encrypt hash, chosen at random
- 6Pu0EK0AzfCjxjv2hoLOB/: Encrypted hash
  The salt and the unencrypted password are combined and encrypted to create the password hash. The use of a salt prevents two users with the same password from having identical entries in /etc/shadow.

Transcript:

In the distant past, encrypted passwords were stored in the world-readable /etc/passwd file. This was thought to be reasonably secure until dictionary attacks on encrypted passwords became common. At that point, the encrypted passwords, or "password hashes," were moved to the more secure /etc/shadow file. This new file also allowed password aging and expiration features to be implemented.

There are three pieces of information stored in a modern password hash:

$1$gCjLa2/Z$6Pu0EK0AzfCjxjv2hoLOB/

1:The hashing algorithm. The number 1 indicates an MD5 hash. The number 6 appears when a SHA-512 hash is used.
gCjLa2/Z:The salt used to encrypt the hash. This is originally chosen at random. The salt and the unencrypted password are combined and encrypted to create the encrypted password hash. The use of a salt prevents two users with the same password from having identical entries in the /etc/shadow file.
6Pu0EK0AzfCjxjv2hoLOB/:The encrypted hash.

User Passwords

Logging in with an Encrypted Password

When user types password and logs in, system:
- Looks up entry in /etc/shadow
- Combines salt with unencrypted password
- Encrypts them using hashing algorithm specified
Result:
- If result matches encrypted hash, user entered correct password
- If result does not match, login attempt fails
This login method allows system to determine if user entered correct password without storing password in usable form

User Passwords

Hashing Algorithms

Support for two password hashing algorithms:
- SHA-256 (algorithm 5)
- SHA-512 (algorithm 6)
Salt string and encrypted hash are longer
Default algorithm used for password hashes can be changed by root
- Run authconfig --passalgo with argument md5, sha256, or sha512
Default is SHA-512

User Passwords

Format of /etc/shadow Entries

Nine colon-separated fields:
name:password:lastchange:minage:maxage:warning:inactive:expire:blank

Field

Description

name

Must be valid account name

password

Password field that starts with exclamation mark means password is locked

lastchange

Date of last password change, represented as number of days since 1970.01.01

minage

Minimum number of days before password can be changed (0 means no minimum age requirement)

maxage

Maximum number of days before password must be changed

warning

Alert that password is about to expire, represented in days (0 means no warning given)

inactive

Number of days account remains active after password expires

User can change password during this period
After specified number of days, account is locked and becomes inactive

expire

Account expiration date, represented as number of days since 1970.01.01

blank

Reserved for future use

User Passwords

Password Aging

To implement password-aging policy, use chage
```
[root@server1~]# chage -m 0 -M 90 -W 7 -I 14 username
```
- To force password update on next login, use chage -d 0 username
- To list current settings, use chage -l username
- To expire account on specific day, use chage -E YYYY-MM-DD

To calculate a future date, use date:

[student@server1 ~]$ date -d "+45 days"
Sat Mar 22 11:7:06 EDT 2014

User Passwords

Restricting Access

To set account expiration date, use chage
- After that date, user cannot log in

To lock account, use usermod -L

[student@server1 ~]$ sudo usermod -L elvis
[student@server1 ~]$ su - elvis
Password:elvis
su: Authentication failure

To lock and expire account with single usermod command:
```
[student@server1 ~]$ sudo usermod -L -e 1 elvis
```
Lock account to prevent access when employee leaves company
- If employee returns, unlock account with usermod -U USERNAME
- If account was expired, change expiration date

User Passwords

nologin Shell

User needs account with password to authenticate to system, but does not need interactive shell
- Example: Mail server requires account to store mail and password to authenticate mail client

Solution: Set user’s login shell to /sbin/nologin

If user tries to log in to system directly, nologin shell closes connection

[root@server1~]# usermod -s /sbin/nologin student
[root@server1~]# su - student
Last login:Tue Feb  4 18:40:30 EST 2014 on pts/0
This account is currently not available.

nologin shell prevents interactive use of system, but does not prevent all access
- User may be able to authenticate and upload or retrieve files through web applications, file transfer programs, mail readers, and so on

References

Man pages: chage(1), usermod(8), shadow(5), and crypt(3)

Transcript:

Sometimes a user needs an account with a password to authenticate to a system, but does not need an interactive shell on the system. For example, a mail server may require an account to store mail and a password for the user to authenticate with a mail client used to retrieve mail. That user does not need to log directly into the system.

A common solution to this situation is to set the user’s login shell to /sbin/nologin. If the user attempts to log into the system directly, the nologin "shell" will simply close the connection.

Use of the nologin shell prevents interactive use of the system, but does not prevent all access. A user may still be able to authenticate and upload or retrieve files through applications such as web applications, file transfer programs, or mail readers.

Identity Management Services

Centralized Identity Management

Modern computer infrastructures consist of many machines running multiple services
Difficult to keep local user accounts and services in sync
Solution:
- Do not store account information on local systems
- Retrieve it from a centralized store
  - Centralized user and authentication information allows for SSO
  - User authenticates once and obtains ticket or cookie that automatically authenticates to other services

Identity Management Services

Centralized identity management system must provide at least two services:
1. Account information
  - Information such as a username, home directory, UID and GID, group memberships, etc.
  - Popular solutions include LDAP and NIS
2. Authentication information
  - Means for system to validate user:
    Provide cryptographic password hash to client system
    Send encrypted password to server and receive response
  - LDAP server provides both authentication and account information
  - Kerberos provides only SSO authentication
    Typically used with LDAP
    Used in both IPA Server and Active Directory
In Red Hat Enterprise Linux 7:
- /etc/passwd provides local user information
- /etc/shadow provides authentication information (hashed password)

Transcript:

A centralized identity management system will need to provide at least two services:

Account information: This includes information such as a username, home directory location, UID and GID, group memberships, etc. Popular solutions include LDAP (Lightweight Directory Access Protocol), used in multiple products such as Active Directory and IPA Server, and Network Information Services (NIS).
Authentication information : A means for a system to validate that a user is who he/she claims to be. This can be done by providing a cryptographic password hash to the client system, or by sending the (encrypted) password to the server, and receiving a response. An LDAP server can provide authentication information in addition to account information. Kerberos only provides SSO authentication services, and is typically used alongside LDAP user information. Kerberos is used in both IPA Server and Active Directory.

On a Red Hat Enterprise Linux 7 system, local user information is provided by /etc/passwd, while authentication information (in the form of a hashed password) is provided by /etc/shadow.

Identity Management Services

Attaching System to Centralized LDAP and Kerberos Servers

At a minimum, update the following files:

File

Purpose

/etc/ldap.conf

Information about central LDAP server and its settings

/etc/krb5.conf

Information about central Kerberos infrastructure

/etc/sssd/sssd.conf

Configuration information for sssd, the daemon responsible for retrieving and caching user and authentication information

/etc/nsswitch.conf

Tells system which user information and authentication services should be used

/etc/pam.d/*

Configures how authentication should be handled for services

/etc/openldap/cacerts

Stores root CAs that validate SSL certificates used to identify LDAP servers

The sssd daemon must be enabled and started before the system can use it.

Transcript:

Configuring a Red Hat Enterprise Linux 7 system to use centralized identity management services requires the editing of various files, and the configuration of some daemons. For attaching to central LDAP and Kerberos servers, the following files, at a minimum, would need to be updated:

`/etc/ldap.conf`contains information about the central LDAP server and its settings.
/etc/krb5.conf contains information about the central Kerberos infrastructure.
/etc/sssd/sssd.conf contains configuration information for the system security services daemon (sssd), which is the daemon responsible for retrieving and caching user information and authentication info.
/etc/nsswitch.conf indicates to the system which user information and authentication services should be used.
`/etc/pam.d/*`configures how authentication should be handled for various services.
/etc/openldap/cacerts stores the root certificate authorities (CA) that can validate the SSL certificates used to identify LDAP servers.

The sssd daemon will need to be enabled and started before the system can use it.

Identity Management Services

authconfig

Suite of tools to automate configuration
- Ships with Red Hat Enterprise Linux 7
Consists of three related tools that perform same actions:
- authconfig: Command line tool
  - Can use to automate configurations across systems
  - Commands tend to be long with multiple options
  - Installed with authconfig package
- authconfig-tui: Interactive version of authconfig
  - Menu-driven text interface
  - Can use over SSH connection
  - Installed with authconfig package
- authconfig-gtk: Graphical interface
  - Can launch as system-config-authentication
  - Installed with authconfig-gtk package

Transcript:

With this number of files and services to configure, a mistake is easily made. Red Hat Enterprise Linux 7 ships with a suite of tools to automate these configurations:authconfig. authconfig consists of three related tools that can all perform the same actions:

authconfig:A command-line tool. This tool can be used to automate configurations across a number of systems. The commands used with authconfig tend to be very long, with multiple options being passed in. This tool is installed using the authconfig package.
authconfig-tui:The interactive version of authconfig. Uses a menu-driven text interface. Can be used over ssh. This tool is installed using the authconfig package.
authconfig-gtk:This version launches a graphical interface. It can also be launched as system-config-authentication. This tool is installed using the authconfig-gtk package.

Identity Management Services

LDAP Parameters

To connect to central LDAP server, authconfig needs these settings:
- LDAP server hostname
- Base DN part of LDAP tree where system should look for users
  - Typically looks like dc=example,dc=com or ou=People,o=PonyCorp
  - Provided by LDAP server administrator
- Root CA certificate that can validate certificates offered by LDAP server
  - Required if using SSL/TLS to encrypt communications with LDAP server
System needs extra packages to provide LDAP client functionality
- Installing sssd provides these dependencies

Identity Management Services

Kerberos Parameters

To use centralized Kerberos system for user authentication, authconfig needs these settings:
- Kerberos realm name
  - Domain of machines using common set of Kerberos servers and users for authentication
- One or more KDC
  - Kerberos server hostnames
- Admin server hostnames
  - Machine that clients talk to when they want to change password or perform other user modifications
  - Typically same as primary KDC, but can be different machine
Administrator can specify if DNS should be used to look up realm for specific hostname and to automatically find KDCs and admin servers
To help debug Kerberos issues and work with Kerberos tickets from command line, install krb5-workstation package

Transcript:

To configure a system to use a centralized Kerberos system for user authentication, authconfig will need the following settings:

The name of the Kerberos realm to use. A Kerberos realm is a domain of machines that all use a common set of Kerberos servers and users for authentication.
One or more key distribution centers (KDC). This is the host name of your Kerberos server(s).
The host name of one or more admin servers. This is the machine that clients will talk to when they want to change their password, or perform other user modifications. This is typically the same as the primary KDC, but it can be a different machine.

In addition, an administrator can specify if DNS should be used to look up the realm to use for a specific host name, and to automatically find the KDCs and admin servers. An extra package can be installed to help debug Kerberos issues, and to work with Kerberos tickets from the command line:krb5-workstation.

Identity Management Services

Using authconfig-gtk

Install the necessary packages:

[student@demo ~]$ sudo yum -y install authconfig-gtk sssd krb5-workstation

Launch authconfig-gtk from command line or Applications → Sundry → Authentication and enter root password.
On Identity & Authentication tab, select LDAP from User Account Database drop-down and fill in LDAP Search Base DN and LDAP Server.
If LDAP server supports TLS, select Use TLS to encrypt connections and then Download CA Certificate.
From Authentication Method drop-down, select Kerberos password. Fill in Realm, KDCs, and Admin Servers.
If central home directories are not available, click Advanced Options tab and select Create home directories on the first login.
Click Apply to save and activate changes. This writes all relevant configuration files and restarts sssd.

authconfig-gtk

Transcript:

To use authconfig-gtk to configure a system for LDAP + Kerberos, use the following steps:

Install all the necessary packages:

Launch authconfig-gtk, either from the command line or from Applications > Sundry > Authentication. Enter the root password when prompted.
On the Identity & Authentication tab, select LDAP from the User Account Database drop-down. Fill out the LDAP Search Base DN and LDAP Server fields.
If the LDAP server supports TLS, check the Use TLS to encrypt connections box, and use the Download CA Certificate button to download the CA certificate.
From the Authentication Method dropdown, select Kerberos password, and fill out the Realm, KDCs, and Admin Servers fields. The last two fields are not available if the Use DNS to locate KDCs for realms option is checked.
If central home directories are not available, users can create directories on first login by checking the Create home directories on the first login box on the Advanced Options tab.
Click the Apply button to save and activate the changes. This will write all relevant configuration files and (re)start the sssd service.

Identity Management Services

Testing a Configuration

To test LDAP and Kerberos, log in to system, using SSH, with credentials of network user
Use getent to retrieve information about network user:
```
getent passwd <USERNAME>
```
Default sssd configuration does not enumerate network users when username is not specified with getent

Identity Management Services

Attaching a System to an IPA Server

Use IPA Server to configure LDAP and Kerberos
IPA Server provides LDAP and Kerberos combined with command line and web tools
IPA Server can centralize the following and more:
- sudo rules
- SSH public keys
- SSH host keys
- TLS certificates
- Automounter maps

Identity Management Services

Using ipa-client-install

ipa-client-install is part of ipa-client package
- Pulls in all dependencies (such as sssd)
- Retrieves most required information from DNS
- Creates host entries on IPA server
- Allows IPA server administrator to set access policies for host, create service principals and more
Without arguments, ipa-client-install tries to retrieve DNS information about IPA server configured for its DNS domain
If retrieval fails, it prompts administrator for:
- Domain name of IPA server
- Realm to use
- Username and password of account allowed to create new machine entries on IPA server
  - Can use default IPA server admin account or another account created for this purpose

Transcript:

A Red Hat Enterprise Linux 7 system can be configured to use an IPA server using the authconfig suite of tools, but a specialized tool also exists: ipa-client-install. This command can be installed from the ipa-client package, which pulls in all dependencies (such as sssd).

One of the benefits of using ipa-client-install is that it can retrieve almost all necessary information from DNS (when configured either by the IPA server or manually by an administrator), as well as create host entries and more on the IPA server. This allows an IPA server administrator to set access policies for that host, create service principals (e.g., for NFSv4 exports), and more.

When ipa-client-install is run without any arguments, it will first attempt to retrieve information about the IPA server configured for its DNS domain from DNS. If that fails, it will prompt the administrator for the necessary information, such as the domain name of the IPA server and the realm to use. Other information that needs to be provided are the username and password of an account that is allowed to create new machine entries on the IPA server. Unless another account has been created for this, the default IPA server administrator account (admin) can be used for this.

Identity Management Services

DNS-Driven Configuration

[student@desktop ~]$ sudo ipa-client-install
Discovery was successful!
Hostname:desktop.domain0.example.com
Realm:DOMAIN0.EXAMPLE.COM
DNS Domain:server.domain0.example.com
IPA Server:server.domain0.example.com
BaseDN:dc=server,dc=domain0,dc=example,dc=com

Continue to configure the system with these values? [no]:yes
User authorized to enroll computers:admin
Synchronizing time with KDC...
Password for admin@DOMAIN0.EXAMPLE.COM:redhat123
Successfully retrieved CA cert
    Subject:    CN=Certificate Authority,O=DOMAIN0.EXAMPLE.COM
    Issuer:     CN=Certificate Authority,O=DOMAIN0.EXAMPLE.COM
    Valid From: Thu Feb 27 13:31:04 2014 UTC
    Valid Until:Mon Feb 27 13:31:04 2034 UTC

Enrolled in IPA realm DOMAIN0.EXAMPLE.COM
Created /etc/ipa/default.conf
New SSSD config will be created
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm DOMAIN0.EXAMPLE.COM
Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
SSSD enabled
Configured /etc/openldap/ldap.conf
Configured /etc/ssh/ssh_config
Configured /etc/ssh/sshd_config
Client configuration complete.

Reference

ipa-client-install(1) man page

Identity Management Services

Joining a System to Active Directory

Can install samba-winbind package and use authconfig to configure winbind
Can install sssd and realmd packages and use sssd and realm commands
- realm can also be used to join Kerberos realms or IPA server domains, but final configuration is different
  - Users have @domain appended to their usernames
  - ipa-client-install is preferred way to join IPA domains

Identity Management Services

Example: Joining an Active Directory Domain

Install realmd package:
```
[student@demo ~]$ yum -y install realmd
```

Discover settings for domain.example.com:

[student@demo ~]$ sudo realm discover domain.example.com

Join Active Directory domain to install required packages and configure sssd, pam, /etc/nsswitch.conf, etc.
```
[student@demo ~]$ sudo realm join domain.example.com
```
- Enter password for Administrator account when prompted
- To use a different account, use --user
Active Directory accounts are usable on local system, but logins using Active Directory are disabled.
- To enable logins:
  [student@demo ~]$ sudo realm permit --realm domain.example.com --all
- To allow only certain users to log in, replace --all with list of users:
  [student@demo ~]$ sudo realm permit --realm domain.example.com DOMAIN\\Itchy DOMAIN\\Scratchy

Transcript:

The following is an example of using realmd to join an Active Directory domain, and allow Active Directory users to log into the local system. This example assumes that the Active Directory domain is called domain.example.com.

Install the necessary packages:realmd.
Discover the settings for the domain.example.com domain.
Join the Active Directory domain; this will install all necessary packages, and configure sssd, pam, /etc/nsswitch.conf, etc.
This command attempts to join the local system to Active Directory using the Administrator account; enter the password for this account when prompted. To use a different account, use the --user argument.
Active Directory accounts are now usable on the local system, but logins using Active Directory are still disabled.
- To enable logins, use the following command:
- To only allow certain users to log in, replace --all with a list of those users. For example:

Identity Management Services

Active Directory Logins

By default, domain users must use a fully qualified name to log in
- Example: ipauser@ipa.example.com for IPA users
- Example: DOMAIN\Picard for Active Directory users
To disable fully qualified names, do one of the following in correct domain block in /etc/sssd/sssd.conf:
- Change use_fully_qualified_names to False
- Remove use_fully_qualified_names setting entirely and restart sssd

References

Man pages: authconfig(8), authconfig-tui(8), authconfig-gtk(8), sssd(8),sssd-ipa(8), sssd.conf(5), sssd-ad, and realm(8)

Summary

Users
Groups
Superuser Access
Local User Accounts
Local Group Accounts
User Passwords
Identity Management Services

Module Completion

Nice job!

Click the button below to complete this module of the course: